Why

• When Airflow runs under one AWS account but writes logs to a bucket owned by another account, S3 (ACL-enabled) makes the writing account the object owner, so the bucket owner cannot read or manage the logs.
• Setting the bucket-owner-full-control ACL on upload is the standard remedy, but the S3 remote log handler previously had no way to set any ACL.

How

• Add an acl_policy field to S3RemoteLogIO; when set, write() passes it as the ACL argument to the underlying put_object call.

Verification

• Real two-account AWS e2e: A bucket under account A set to Bucket owner preferred. A task run under account B writing logs to account A's bucket:
  • Round 1 — no ACL: account A (bucket owner) gets AccessDenied reading the uploaded log.
  • Round 2 — s3_task_handler_acl_policy = bucket-owner-full-control: account A can read the log, and object ownership transfers to the bucket owner.

• closes: Support specify s3 object ACL args for remote logging #8917

Was generative AI tooling used to co-author this PR?

• Yes - Claude Code

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.